📚 Week 4 · Unit II · Lecture 11
Infrastructure Automation;
RCA & Blamelessness

Automating infrastructure at scale, diagnosing failures through Root Cause Analysis, building blameless cultures, and turning every incident into organizational learning.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateMon, 29 Jun 2026 · 11:00 AM – 12:00 PM
ProgrammeBTech CSE – Summer Semester
Today's Agenda
1
Recap — CAMS Complete, Configuration Management
2
Infrastructure Automation — Beyond CM
3
IaC Patterns — Immutable Infra & Containers
4
Root Cause Analysis — 5 Whys & Fishbone
5
Blameless Post-Mortems — Structure & Practice
6
Organizational Learning & Unit II Wrap-Up
Recap
Where We Left Off
Lecture 10: We completed the CAMS framework — Measurement (DORA four key metrics, meaningful vs. vanity metrics) and Sharing (knowledge distribution, bus factor, ChatOps). We then introduced Configuration Management — pets vs. cattle, IaC, and CM tools like Ansible, Puppet, Chef, and Terraform.
🎯
Today: We go deeper into Infrastructure Automation patterns, then shift to the human side — Root Cause Analysis techniques, Blameless Post-Mortems, and Organizational Learning. This is the final lecture of Unit II, tying together all the DevOps principles we've covered.
Unit II Journey (Lectures 6–11)
  • L6: DevOps intro, DevOps & Agile ✔️
  • L7: MVP, Application Deployment ✔️
  • L8: CI/CD pipelines ✔️
  • L9: CAMS: Culture & Automation, TDD ✔️
  • L10: CAMS: Measurement & Sharing, CM ✔️
  • L11: Infra Automation, RCA, Learning 📍
Why This Lecture Matters
  • Infrastructure automation scales what CM started — from servers to entire environments
  • RCA and blamelessness turn failures into the most valuable learning opportunities
  • Organizational learning closes the loop — making the whole team smarter after every incident
Infrastructure Automation
Beyond Configuration Management
🏗️
Infrastructure Automation extends CM to the full lifecycle of infrastructure — not just configuring servers, but provisioning, scaling, monitoring, and decommissioning them automatically. The goal: zero manual touch from request to running service.
📦
Provisioning
Automatically create VMs, networks, databases, and load balancers. Tools: Terraform, AWS CloudFormation, Azure ARM Templates, Pulumi.
⚙️
Configuration
Set up the software inside provisioned resources — packages, users, files, services. Tools: Ansible, Puppet, Chef, SaltStack.
📈
Orchestration
Coordinate multi-step deployments across many servers — rolling updates, blue-green deploys, canary releases. Tools: Kubernetes, Docker Swarm, Nomad.
📊
Monitoring & Healing
Detect failures and auto-remediate — restart crashed services, scale up under load, replace unhealthy nodes. Tools: Prometheus + AlertManager, Datadog, PagerDuty.
🔗 The Automation Spectrum

Infrastructure Automation moves through four levels: ManualScripted (bash scripts) → Declarative IaC (Terraform, Ansible) → Self-Healing (Kubernetes auto-scaling, auto-restart). The goal is to push as far right as practical.

IaC Pattern
Immutable Infrastructure

Instead of updating servers in place (mutable), you replace them entirely with new, pre-built images. Every change = a new image, not a patch on the old one.

🔄 Mutable (Traditional)
  • Update packages on running servers via SSH
  • Each server accumulates unique patches over time
  • Drift between servers — "works on server A but not B"
  • Rollback is painful — undo each change manually
  • Hard to reproduce the exact state of any server
🔒 Immutable (Modern)
  • Build a new image (AMI, Docker image) with all changes baked in
  • Deploy by replacing old instances with new ones
  • Every instance is identical — zero drift
  • Rollback = redeploy the previous image (seconds, not hours)
  • Full reproducibility — the image is the documentation
Code ChangeApp or infra
Build ImageDocker / AMI
Test ImageAutomated tests
Deploy NewReplace old
Destroy OldClean up
🐳
Containers are immutable infrastructure. A Docker container is built from a Dockerfile, producing an identical image every time. You never SSH into a container to fix it — you rebuild the image and redeploy. This is immutability in practice.
Containers & Orchestration
Containers as Infrastructure Units

Containers package an application with all its dependencies into a single, portable unit. Orchestrators manage fleets of containers at scale.

# Example: Dockerfile for a Node.js application
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
VM
Minutes to
boot, GBs
🐳
Seconds to
start, MBs
K8s
Auto-scale
Auto-heal
Identical
anywhere
☸️
Kubernetes (K8s) is the industry standard container orchestrator. It handles scheduling, scaling, rolling updates, self-healing (restart failed containers), service discovery, and load balancing — all declaratively defined in YAML manifests.
Incident Response
Why Incidents Happen — A Systems View

Every system is perfectly designed to get the results it gets. If your system produces failures, look at the system, not the person who triggered the failure.

— W. Edwards Deming (adapted)
Complex Systems Fail
Modern distributed systems have millions of interactions. Failures aren't caused by one mistake — they emerge from the interaction of multiple contributing factors.
🧊
Latent Conditions
Most failures have "latent" preconditions — misconfigurations, technical debt, missing alerts — that existed long before the triggering event.
👤
Human Error Is a Symptom
When someone "causes" an outage, ask: why did the system allow that action? Why wasn't there a safety net? The human is the last link, not the root cause.
🚨
Key shift: Traditional thinking asks "Who caused this?" — DevOps thinking asks "What in our system allowed this to happen, and how do we prevent it systemically?" This is the foundation of blamelessness and Root Cause Analysis.
Root Cause Analysis
RCA Techniques: The 5 Whys

Root Cause Analysis (RCA) is a structured method for identifying the underlying cause of a problem — not just the surface symptom. The simplest technique is the 5 Whys.

🔍
The 5 Whys: Start with the problem and ask "Why?" repeatedly (typically 5 times) until you reach a systemic root cause. The key rule: each answer must describe a system condition, not blame a person.
W1
Problem: The website went down for 30 minutes
Why? The database ran out of disk space.
W2
Why did the database run out of disk space?
Old log files were never cleaned up — they grew to 500 GB.
W3
Why were old log files never cleaned up?
There was no automated log rotation configured for that database.
W4
Why was there no automated log rotation?
The database was set up manually, and log rotation wasn't in the setup checklist.
W5
Why wasn't log rotation in the setup checklist?
Root Cause: Database provisioning is manual and lacks an IaC template that includes log rotation by default.
💡 The Fix

Action item: Create an Ansible/Terraform template for database provisioning that includes automated log rotation, disk space monitoring, and alerts at 80% capacity. This prevents the entire class of failures, not just the one incident.

RCA Techniques
Ishikawa (Fishbone) Diagram

For complex incidents with multiple contributing factors, the Fishbone Diagram (Ishikawa) organizes potential causes into categories. It's useful when the 5 Whys leads to multiple branches.

People
Insufficient training No on-call rotation Knowledge in one person's head
Process
No change approval Missing runbook No staging test before prod
Tools
No monitoring alerts Outdated CI/CD pipeline Missing rollback automation
Environment
Staging ≠ Prod config Network latency spike Cloud provider rate limits
📋
How to use it: Draw the "spine" (problem statement) on the right, then brainstorm causes in each category. Multiple causes from different categories often combine to produce a failure. The fishbone reveals systemic patterns — e.g., "we keep having People + Process failures → we need better onboarding and runbooks."
When to Use 5 Whys
  • Simple, linear incident with a clear chain of events
  • Quick post-mortem needed (15–30 min)
  • Single failure mode — one thing went wrong
When to Use Fishbone
  • Complex incident with multiple contributing factors
  • Deep-dive post-mortem (1–2 hours)
  • Recurring failures — need to find systemic patterns
Blamelessness
What Blamelessness Really Means

Blamelessness does not mean accountability-free. It means we hold the system accountable for allowing the failure — and we hold people accountable for learning from it and improving the system.

— John Allspaw, former CTO of Etsy
🚫 Blame-Driven Response
  • "Who did this?" → finds a name, not a fix
  • Punish the person → they hide mistakes next time
  • Fear spreads → people stop taking risks or flagging issues
  • Same failure happens again — because the system wasn't fixed
  • Post-mortem becomes a trial — nobody is honest
✅ Blameless Response
  • "What allowed this?" → finds a systemic cause
  • Fix the system → add guardrails, automation, alerts
  • Safety spreads → people report near-misses early
  • Failure rate drops — because the system gets stronger
  • Post-mortem becomes a learning session — everyone contributes
⚠️
Common misconception: "Blameless means nobody is responsible." No — people are still accountable for following processes. But when the process itself fails, you fix the process, not the person. If someone can accidentally delete production with one command, the problem is that the command exists — not that someone ran it.
Post-Mortem
Anatomy of a Blameless Post-Mortem

A blameless post-mortem is a structured meeting held after an incident, focused on learning and prevention — never on punishment. Here's the standard template used by companies like Google, Etsy, and Netflix.

1
Incident Summary
What happened? When? How long was the impact? How many users were affected? A factual, one-paragraph description — no blame, just data.
2
Timeline of Events
A minute-by-minute timeline: when the issue started, when it was detected, what actions were taken, when it was resolved. Include who did what — as a record, not as blame.
3
Root Cause Analysis
Apply the 5 Whys or Fishbone to find the systemic root cause. Focus on system conditions, not individual actions. "The deploy script lacked a rollback check" — not "Dev X forgot to check."
4
Contributing Factors
List everything that made the incident possible or worse: missing monitoring, lack of staging tests, unclear runbooks, team fatigue, etc.
5
Action Items (with Owners & Deadlines)
Concrete, measurable fixes: "Add disk space alert at 80% — owned by Ops team — due by July 5." Without action items with deadlines, a post-mortem is just storytelling.
🌐
Share it widely. Post the post-mortem to an internal wiki or Slack channel — not just the team that was involved. Other teams learn from your failures, preventing the same issue across the organization. This is "Sharing" from CAMS in action.
Real-World Example
Post-Mortem in Practice: SRE at Google

Google's Site Reliability Engineering (SRE) team has published their post-mortem culture and templates. Here are their guiding principles.

📝
Write It Down
Every significant incident gets a written post-mortem. It's a living document — updated as new information surfaces. Verbal-only retros are insufficient.
🤝
Blameless by Default
Google SRE's post-mortem template explicitly removes blame language. The focus is: "What did we learn?" and "What will we change?" — never "Who made the mistake?"
📊
Track Action Items
Post-mortems without follow-up are useless. Google tracks every action item in a bug tracker with owners and SLAs. Unresolved items are escalated.
Principle What It Means
Assume good intent Everyone involved was trying to do the right thing with the information they had at the time
Focus on systems Ask how the system, tools, and processes allowed the failure — not why a person failed
No counterfactuals Don't say "If only they had…" — focus on what actually happened and what to change going forward
Celebrate the post-mortem Writing a post-mortem should be seen as a positive contribution, not a chore or punishment
Organizational Learning
From Incidents to Intelligence
🧠
Organizational Learning is the process by which an organization acquires, retains, and transfers knowledge — so that the entire team gets smarter from every incident, not just the people who were on-call that night.
🔥
Incident
Something breaks
🔍
Analyze
RCA + Post-mortem
📖
Learn
Document & share
🛡️
Prevent
Fix system & automate
💪
Stronger
Resilient org
🔄
The Learning Loop never stops. Each incident is an opportunity to make the system more resilient. Organizations that learn fastest from failures outperform those that try to prevent all failures — because in complex systems, failures are inevitable.
Theory Foundation
Senge's Learning Organization

Peter Senge's The Fifth Discipline (1990) defined the concept of a "Learning Organization." DevOps adopted these ideas directly.

🎯
Personal Mastery
Individuals commit to lifelong learning — staying current with new tools, practices, and techniques. DevOps teams invest in training and experimentation time.
🧠
Mental Models
Challenge assumptions — "We've always done it this way" is the enemy. DevOps challenges the wall between Dev and Ops as a flawed mental model.
🌟
Shared Vision
The entire team aligns on a common goal — fast, reliable delivery of value to users. Not "Dev ships fast" vs. "Ops keeps things stable."
👥
Team Learning
Teams learn together through retrospectives, post-mortems, pair programming, and shared on-call. Collective intelligence > individual brilliance.
🔗
Systems Thinking
See the whole system, not just your part. An Ops problem is a Dev problem is a business problem. This is "the fifth discipline" — and it's the heart of DevOps.
🔑 Connection to DevOps

Every CAMS pillar maps to Senge's disciplines: Culture = mental models + shared vision, Automation = personal mastery with tools, Measurement = systems thinking with data, Sharing = team learning. DevOps is a learning organization applied to software delivery.

Practices
Building a Learning Organization

Concrete practices that transform incidents into organizational intelligence.

📚 Knowledge Capture
  • Post-Mortem Library — searchable archive of all past incidents and their fixes
  • Runbooks — step-by-step operational guides, kept up-to-date after every incident
  • Architecture Decision Records (ADRs) — document why decisions were made, not just what
  • Internal Blogs / RFCs — engineers write about what they learned and share proposals
🔄 Knowledge Transfer
  • Failure Friday / Game Day — intentionally inject failures and practice the response
  • Rotation Programs — engineers rotate across Dev, Ops, and SRE teams
  • Shadowing On-Call — new team members shadow experienced on-call engineers
  • Weekly Incident Review — entire team reviews one past incident for lessons
🎮
Chaos Engineering (pioneered by Netflix) takes this further: deliberately introduce failures in production to test resilience. The tool Chaos Monkey randomly terminates production instances to ensure the system can handle it. If your system can't survive one server dying, you'll find out on a Tuesday morning — not during a holiday traffic spike.
Summary & Unit II Wrap-Up
Key Takeaways — Lecture 11 & Unit II

This lecture completed Unit II by connecting infrastructure automation with the human practices that make DevOps sustainable — RCA, blamelessness, and organizational learning.

01
Infrastructure AutomationGoes beyond CM — covers provisioning, config, orchestration, and self-healing. Immutable infrastructure and containers eliminate drift and enable instant rollbacks.
02
Root Cause AnalysisUse the 5 Whys for simple incidents and Fishbone diagrams for complex ones. Always seek systemic causes, not individual blame.
03
Blameless Post-MortemsStructured documents with timeline, RCA, contributing factors, and action items. Share widely. Assume good intent. Fix systems, not people.
04
Organizational LearningIncidents → Analysis → Learning → Prevention → Stronger. Senge's five disciplines provide the theoretical foundation. DevOps is a learning organization.
05
Unit II CompleteFrom DevOps + Agile (L6) through MVP, CI/CD, CAMS, TDD, CM, infra automation, and learning — Unit II gave you the full DevOps philosophy and practices.
06
Up Next: Unit IIITypical toolkit for DevOps, CI/CD tooling in depth, and Version Control Systems — moving from principles to hands-on tools.
🎯
Exam tip: Be able to explain the 5 Whys with a worked example. Know the structure of a blameless post-mortem (5 sections). Understand immutable vs. mutable infrastructure. Know Senge's five disciplines and how they map to CAMS. Distinguish "blame" from "accountability" in DevOps culture.